fix(kanban): keep the swimlane column-header row out of the flex shrink pool - #8430

Fixes #7303

What the card said, re-derived on my own base (0203a29e9)

Every number in the card still holds. The three-layer ancestor chain it measured is
literally these lines, and the tag difference it noticed is real:

Root cause: a flexbox rule, not a paint bug

The header row is a flex item of the swimlane region (flex-col, inside a
height-bounded h-full board). overflow-x-auto makes it a scroll container, and a
flex item's automatic minimum size (min-height: auto) applies only while its overflow
is visible — so a scroll container may legally be shrunk to height 0. The lanes below
keep overflow: visible, so their automatic minimum size clamps them at content height
and they refuse to shrink. Once the lanes overflow the board, the entire deficit lands
on the one shrinkable item. Measured computed styles on the broken build:

headerRow  flex-shrink 1  min-height auto  overflow-x auto     overflow-y auto     height 0.0
firstLane  flex-shrink 1  min-height auto  overflow-x visible  overflow-y visible  height 674.5

The fix is shrink-0 on that row — one class, no layout decisions taken.

⚠️ The trigger decides who saw this: the collapse needs the lanes to overflow the
board. The same fixture with 45 cards instead of 150 renders the row at 24px on the
broken build. So in the field this presents as "sometimes the column labels are missing",
not as a flat breakage of swimlanes.

Measured, in a real browser, on this component's own markup

Chromium 1194 @ 1600×1000, the real rendered DOM of KanbanRenderer + Tailwind-generated
CSS, lanes overflowing a 1000px board:

The pin — and what it honestly is

⚠️ A "the header row exists" assertion passes on the broken build — the row was there,
in the right place, holding all five titles, at height 0. And vitest runs in happy-dom,
which performs no layout: a height assertion there could not fail in either world. So
packages/plugin-kanban/src/__tests__/swimlaneColumnHeaderRow-7303.test.tsx asserts the
style contract that decides the height, stated as an invariant rather than one blessed
spelling: the row must not be both a scroll container and shrinkable (shrink-0,
flex-shrink-0, an inline flexShrink, or a min-h-* floor all satisfy it; overflow-*-hidden
and -clip count as scroll containers, because they zero the auto minimum size too).

The docstring says all of this in the file, including the browser numbers above, so nobody
later reads it as a height measurement.

Ablation — two mutations, from the committed implementation, each restored by state:

Restore verified by state after each (git hash-object back to the HEAD blob and
git diff HEAD empty), never by an exit code.

Would something strictly worse than the bug pass? No — that is what the second mutation
above tests. Deleting the swimlane header row, or the swimlane layout itself, reddens the
controls: a rendered lane (['▶ann(1)', '▶bob(1)']), a rendered card inside a lane cell,
and the titles read through queryByText into expect(value, message). A separate
NON-REGRESSION case pins the flat board's own <h3 id="kanban-col-open">, so "make
swimlanes render nothing" is not a way through either. The viewport is pinned explicitly
(1600×1000) even though this markup is width-independent — the file says which branch it
describes and that anything width-dependent added later must re-state it.

On the triage seat's boundary #1 (reuse :319 instead of fixing :659)

Confirmed the two header implementations must stay separate, and the reason is now
written at the call site: the swimlane layout has no column components at all — every lane
paints its own row of plain column cells — so the titles have to be drawn once, above every
lane. Reusing KanbanColumnView's <h3> would mean repeating the labels per lane, which is
a product ruling the card does not settle (its Expected says "above the lanes"), so I did
not take it. The comment also pins the shared pl-36 sm:pl-44 indent, and the test asserts
the header row and the lane content rows carry the same indent tokens.

⚠️ Adjacent defects found while measuring — NOT fixed here, and not filed

search_issues returned API rate limit already exceeded for user ID 323634890, so per my
dispatch I did not file unsearched. All three are in my report for the PM to file:

1. Swimlane lanes below the fold are unreachable. The region is overflow-hidden
   (scrollHeight 2104 vs clientHeight 1000) and no ancestor scrolls
   (document.documentElement is not scrollable) — with 3 lanes at 1600×1000, lanes 2 and 3
   cannot be reached at all. Fixing it means choosing where the swimlane board scrolls, which
   is a product ruling.
2. The header row and each lane scroll horizontally out of sync. They are independent
   scroll containers: driving one lane to scrollLeft 298 leaves the header at 0, putting
   the "Open" title at x=200 while the Open cell sits at x=-97. So past this fix, a
   scrolled swimlane board shows labels over the wrong columns. Syncing them means deciding
   whether all lanes scroll together — again a product ruling.
3. The swimlane path ignores the container-aware column sizing. KanbanBoardInner derives
   columnInlineStyle from the board's own measured width and the flat path applies it, but
   the swimlane header cells and lane cells keep the hard-coded w-[85vw] sm:w-80 — so an
   embedded/panelled swimlane board still sizes columns to 85% of the viewport, the exact
   failure that sizing was introduced to remove.

Verification

Proposal — the standing gap this card exposes

Nothing in CI can measure a rendered height: unit tests run in happy-dom (no layout) and the
e2e suite needs a production build of the console. The measurement above is reproducible but
lives outside the repo — real component DOM + Tailwind-compiled CSS + Chromium, roughly 60
lines. packages/plugin-grid/demo/vite.live.config.ts is the precedent for a standalone
harness. Worth a card if the maintainers want layout regressions of this class caught rather
than argued; I did not file one, for the rate-limit reason above.

Left as a draft for the PM's contract review.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YBWFb5YgMU5dw8p2VKj16S

Generated by Claude Code